\chapter{课题结论与改进}
\section{实验结论}

经过第三章对项目功能完整性和性能优越性的测试，得出我们的贡献基本总结为以下几点：

\begin{itemize}
	\item 可以对时间线上所有时刻的异常做出实时性统计并划分出异常域等级，使观者可以通过可视化折线图得出所有时刻区域内的服务器节点运行的大致状态汇总，并作为Level-1入口视图，通过交互功能联动其他的视图来实现对整个系统组件的控制；
	\item 能够在针对性选择观察时刻的基础上，选择某一时间节点下该测试集的任务调度可视化展示，包含了对所有层级(job、task、instance)的可视化输出以及对应的树形节点的从属关系，以及在此基础上显示负载服务器端的运行状态，以此来映射式地观察到客户端的操作对服务器端节点的影响，从而可以判断是否是某一用户所执行的任务对其调度的服务器产生的形象。这种对任务调度异常可视化观察的方法在业内是开拓性的；
	\item 面对时序性需求的挑战采取了合理的方法实现了对某一时刻某节点过往状态的热力图展示，根据第三章的测试结果我们也可以根据视图的功能性得出节点是否是长时间出于高负载的状态，或是突然升高的负载，甚至得出高负载所呈现出的周期性。
	\item 在Level-2层级的第二类组件则可以做到某时刻下的运行参数和固有参数展示，辅助我们对节点本身的性能做出直观而清晰的判断，包括在同一异常等级下两类节点本身的性能和容错率的不同，导致了两类节点均发生异常但是处理方式却因为所观察到的结果而截然不同。
\end{itemize}

总的来说，从系统设计到实现的新颖性和发展性来讲，项目本身从数据可视化的角度出发，关注交叉硬件领域的任务调度问题，目的是解决任务调度的过程中经常出现困扰控制人员却没有先进技术支撑的传统缺点：异常节点的可视输出以及异常原因的可视展示。整个系统具有明显的优点也是可视化本身的特性——直观性，也恰恰解决了现在业内所使用的的调度控制系统的不直观不清晰问题。

\section{实验改进思路}
\subsection{硬件改进}
本次项目的的一大难题，就是对庞大的数据集的处理工作无法展开的问题。本次实验有200余GB的原始数据集，这对一台普通的PC机来说，要处理此类数据文件是完全不可能的事情，因为如今一台很高配置的机器最多也就64GB的运行内存。所以，解决的方法一是以后尽量避免使用规格过大的数据集，二是如果必须要求处理大规格数据文件，可以采用多台服务器串联并行的方法来读取数据，理论上是可行的，不过建设性方面考虑也的确耗时耗力。
\subsection{方法改进}
想要提高系统的执行效率，靠提升硬件的方法上升空间往往是很低的，不如从设计思路和执行方法的角度考虑，效果往往会事半功倍:
\begin{itemize}
	\item 本次项目使用的异步数据请求并行度不高，虽然有部分模块使用Promise的方法集成异步操作使得执行过程已有部分优化，但是好需要重新设计数据流的执行结构，达到企业级的执行效率；
	\item 本项目的交互事件多数都是绑定在可视化组件的元素中来达到交互的目的，但是这种做法会一定程度上降低系统功能性和可操作性的上限，系统的完备性也会受到影响。争取在以后的二次开发上，投入更多的人力和时间成本，来使系统达到更好的操作灵活度；
	\item 在可视化模块的实现方面，还没有做到市场熟练和灵活的使用d3.js，在实现的过程中还是略显僵硬。后期专门会研究d3.js的工作流程和各种svg图形的描绘，使自己能够用它实现各种绚丽多彩的无格式化动态图形，这样才是通透的理解了d3.js，在此基础上才能通过自己对数据结构的理解自由设计出新颖巧妙的可视化图形。这也恰恰是我们选择d3.js实现数据可视化的理由；
	\item 整个模块化的代码结构还需要更加的专业。很多功能不得不说都是通过自己的理解去编写的代码，这样做的结果虽然在功能上实现了，但是很有可能不是最优美、对计算机处理来说最有效率的代码或结构体形式。另外，对官方文档的研究还是不够透彻，后面的项目还需要加强对官方文档的理解；
	\item 项目中使用后端数据库mongoDB的初衷是模拟实际生产情况来对数据进行实时更新，但是这种方式并不是最理想的设计方案，为了提高监测的精准性，建议在项目二次开发的时候改为数据流的形式传入接口，并且实现数据根据传入的数据流动态刷新。这样的做法既提高了状态的实时性，也介绍了后台接口的压力，提高了处理速度及运行效率。
\end{itemize}